REMARKS 



No claims have been amended, added or canceled. Therefore, claims 1-47 remain 
pending in the application. Reconsideration is respectfully requested in light of the 
following remarks. 

Section 102(a) Rejection : 

The Office Action rejected claims 1-7, 9-13, 16-23, 25-29, 31-39, 41-45 and 47 
under 35 U.S.C. § 102(a) as being anticipated by Czerwinski, et al., "An Architecture for 
a Secure Service Discovery Service" (hereinafter, "Czerwinski"). Applicants respectfully 
traverse this rejection in light of the following remarks. 

Regarding claim 1, contrary to the Examiner's assertion, Czerwinski fails to teach 
requesting a capability credential to allow the client to access a portion of the first 
service's capabilities, wherein said requesting a capability credential comprises the client 
indicating a set of desired capabilities . The Examiner cites passages in Czerwinski 
(Sections 3.3 and 3.4) that discuss the certificate authority and the capability manager of 
SDS. Czerwinski describes a secure Service Discovery Service (SDS) wherein a client 
requests a capability credential from a capability manager. However, a SDS client does 
not indicate a set of desired capabilities when requesting a capability credential. Instead, 
each service in the SDS system contacts the capability manager, and "specifies an access 
control list" including a list of principals, such as clients, allowed to access the service's 
description (Czerwinski, section 3.4, paragraph 3). It is only after obtaining a capability 
credential from the CM that a client contacts a SDS Server to locate one or more services. 
The SDS server returns services that match the client's query (Czerwinski, section 3.1, 
paragraph 5). The client presents the capability credential to the SDS server and the 
server only returns services to which the client has access based upon the capability 
credential obtained from the Capability Manager. Thus, a client is granted access to all 
or none of a service's features based on whether that client is included in the service's 
access control list. In other words, SDS services specify which clients can have access to 
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their respective services, but a SDS client does not indicate a set of desired capabilities 
when requesting a capability credential. The capability manager gives the client a 
capability credential that informs the SDS server of which services the client is able to 
access. 

In response to the above argument, the Examiner, in the Response to Arguments 
section of the Final Office Action, states that "Czerwinski discloses a client contacts the 
CA and specifies the principal's certificate that it is interested in," again citing section 3.3 
of Czerwinski. However, a principal's certificate in Czerwinski does not indicate a 
set of desired capabilities. Instead, a principal's certificate is a "public-key certificate 
that can be used to prove the component's identity to all other components" (Czerwinski, 
section 2.4, paragraph 2). Thus, the certificates to which the Examiner is referring 
provide authentication within Czerwinski' s system and do not have anything to do with a 
client indicating a set of desired capabilities. Czerwinski teach that his system uses 
certificates "to authenticate the bindings between principals and their public keys (i.e., 
verifying the digital signatures used to establish the identities of SDS components)" 
(Czerwinski, section 3.3, paragraph 1). 

Czerwinski's client requesting a principal's certificate is not the same as a 
requesting a capability credential where the client indicates a set of desired capabilities, 
as recited in claim 1. As noted above, Czerwinski's certificates provide authentication, 
not any indication of a desired set of capabilities. Furthermore, the Examiner's cited 
passage states that Czerwinski's Certificate Authority provides a principal's certificate to 
a client, and thus, even if Czerwinski's certificates did indicate a set of desired 
capabilities, which they clearly don't, the Examiner's argument still would not provide 
for a client indicating a set of desired capabilities. 

Thus, Czerwinski clearly fails to disclose a client requesting a capability 
credential wherein said requesting a capability credential comprises the client indicating a 
set of desired capabilities, as recited in claim 1. For at least the reasons above, the 
rejection of claim 1 is not supported by the prior art and removal thereof is respectfully 
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requested. Similar remarks as discussed above in regard to claim 1 apply to claims 17 
and 33. 



Regarding claim 2, the Examiner asserts that Czerwinski teaches that requesting a 
capability credential comprises the client sending a capability credential request message, 
wherein said capability credential request message comprises an identification of said 
first service and an indication of the set of desired capabilities . Applicants respectfully 
disagree with the Examiner's interpretation of Czerwinski. In fact, Czerwinski clearly 
fails to disclose a capability credential request message that comprises an identification of 
the first service. The Examiner's cited passages (sections 3.3 and 3.4) disclose how a 
client contacts a capability manager to obtain the client's capabilities, but neither of these 
passages describe a capability credential request message that comprises an indication of 
a service. In contrast, Czerwinski states that SDS services provide an access control list 
including a list of principals, such as clients, allowed to access the service's description 
(Czerwinski, section 3.4, paragraph 3). Czerwinski further states that the capability 
manager "then generates the appropriate capabilities and saves them for later distribution 
to the clients (Czerwinski, section 3.4, paragraph 3). Thus, rather than a client sending a 
capability credential request message that comprises an identification of the service, 
Czerwinski teaches that the identity of the client is matched against access control lists to 
determine which services the client is allowed to discover. 

Additionally, Czerwinski fails to teach that the capability credential request 
message comprises an indication of the set of desired capabilities. As argued above 
regarding claim 1, Czerwinski' s SDS clients do not indicate a desired set of capabilities 
when requesting a capability credential. Instead, they obtain a capability credential that 
allows the SDS server to return only those services that have specifically granted the 
client access (Czerwinski, section 3.1, paragraph 5). Therefore, any capability credential 
request message in SDS would not comprise an indication of a client's set of desired 
capabilities. 
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In response the above arguments, the Examiner states, "Czerwinski discloses the 
first service, which is the SDS service, and the set of desired capabilities" citing section 
3.1, paragraph 5, and section 6.1 of Czerwinski. However, the first cited passage 
describes how a client submits a query to the SDS service along with the client 
capabilities to search for "service descriptions that both match the query and are 
accessible to the user." Czerwinski's SDS service does not provide capability credentials 
to clients. Instead, as noted above, Czerwinski's system includes a capability manager 
that distributes capabilities. A client submitting a query to an SDS service does not 
involve a capability credential request message. Section 6.1 of Czerwinski briefly 
describes the unique service names of both the Internet Domain Naming Service and 
Globe. However, this cited passage makes no mention of capability credentials, 
capability credential request messages, nor any indication of a set of desired capabilities. 
In fact, section 6.1 of Czerwinski is completely irrelevant to a capability credential 
request message comprising an identification of said first service and an indication of the 
set of desired capabilities, as recited in claim 2. 

Thus, the rejection of claim 2 is not supported by the prior art and removal thereof 
is respectfully requested. Similar remarks as discussed above in regard to claim 2 apply 
to claims 18 and 34. 

In regard to claim 3, contrary to the Examiner's contention, Czerwinski fails to 
teach wherein said identification of said first service comprises a Universal Unique 
Identifier (UUED). The Examiner cites section 6.1 of Czerwinski, but this passage only 
states that a different discover service, Globe, uses unique object identifiers to identify 
services, but fails to disclose wherein a capability credential request message comprising 
an identification of a service wherein that identification of the service comprises a UUID. 
In contrast, as shown above regarding claim 2, Czerwinski teaches that clients do not 
identify a service when requesting a capability credential. Hence, any use of UUIDs, or 
"Globe unique object identifiers", in SDS would not involve including a UUID as part of 
an identification of a service in a capability credential request message. Also, the Globe 
unique object identifiers in Czerwinski are not described as UUIDs. Czerwinski clearly 
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fails to teach wherein the identification of the first service comprises a Universal Unique 
Identifier (UUID). 

In response to the above argument, the Examiner states, "Czerwinski discloses 
that the SDS is connected to the client through ARMI, which commonly uses UUID to 
identify the service" citing section 3.1, paragraph 5 and section 3.5.3 of Czerwinski. 
However, as noted above, a client in Czerwinski' s system does not send a capability 
credential request message to an SDS service. Neither of the cited passages mention 
anything about, nor have anything to do with, capability credential request messages. 
Whether or not ARMI uses UUIDs to identify services does not disclose anything about 
the contents of a capability credential request message. The Examiner seems to be 
completely ignoring this limitation of Applicant's claims. 

Furthermore, the Examiner has not established a proper case of anticipation 
because the teachings relied on by the Examiner are from separate works. 

Anticipation requires the presence in a single prior art reference disclosure of each and 
every element of the claimed invention, arranged as in the claim . Lindemann 
Maschinenfabrik GmbH v. American Hoist & Derrick Co., 221 USPQ 481, 485 (Fed. Cir. 
1984). The identical invention must be shown in as complete detail as is contained in the 
claims. Richardson v. Suzuki Motor Co., 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 
Although all the teachings cited by the Examiner are discussed in a single reference, the 
teachings are not part of a single method. For example, the portion of Czerwinski cited 
by the Examiner at section 6.1 is part of Czerwinski' s discussion of related work and 
pertains to a different service discovery system (Globe) than the portion of Czerwinski 
cited by the Examiner at sections 3.3 and 3.4. To anticipate the claimed invention, 
Czerwinski must teach a single method that is identical to Applicants' claimed invention. 
Otherwise, Czerwinski cannot be said to teach the identical invention arranged as in 
Applicants' claims . Moreover, as discussed above, no combination of teachings in 
Czerwinski teaches Applicants' claimed invention. 
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Therefore, the rejection of claim 3 is not supported by the prior art and removal 
thereof is respectfully requested. Similar remarks as discussed above in regard to claim 3 
apply to claims 19 and 35. 

Regarding claim 4, contrary to the Examiner's assertion, Czerwinski fails to 
disclose wherein said capability credential request message is formatted in extensible 
Markup Language (XML). The Examiner cites section 3.1 of Czerwinski. However, this 
passage only describes how a client uses XML to build a service query that is matched 
against various service descriptions by the SDS server. As noted above, a SDS client 
must already have a capability credential obtained from a capability manager prior to 
querying a SDS server. Furthermore, Czerwinski only states that "[s]ervice descriptions 
and queries are specified in extensible Markup Language (XML)" (Czerwinski, section 
1, paragraph 5). Neither service descriptions, nor service queries in SDS are capability 
credential request messages. Czerwinski fails to mention anything about using XML to 
format a capability credential request message. In fact, Czerwinski fails to describe the 
formatting of a capability credential request message at all. Thus, Czerwinski clearly 
fails to disclose wherein said capability credential request message is formatted in 
extensible Markup Language (XML). 

In the Response to Arguments section of the Final Office Action, the Examiner 
response to the above argument by stating, "since the SDS query is in XML format and 
the query contains capabilities . . . [therefore, the capabilities credential request message 
and the credential are communicated in XML format in order to make it easier to 
communicate." This argument by the Examiner is clearly flawed. Firstly, the very fact 
that an SDS query includes capabilities, as admitted by the Examiner, demonstrates that 
the SDS query cannot be a capability credential request message. Secondly, just because 
an SDS query is formatted in XML does not imply that anything else, including a 
capability credential request message, is formatted in XML. As noted above, Czerwinski 
fails to teach anything regarding the format of a capability credential request message. 
Thirdly, the Examiner is incorrect that a capability credential in SDS is communicated in 
XML format. Czerwinski teaches that "capabilities, like certificates, are securely 
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associated with a single principal, and only the clients possessing the appropriate private 
key can use them" (Czerwinski, section 3.4, paragraph 3). Czerwinski's capabilities are 
clearly encrypted and not formatted in XML. The Examiner's argument amounts to 
nothing more than merely speculation and unsubstantiated conclusion unsupported by 
any teaching or suggestion from Czerwinski. 

The rejection of claim 4 is not supported by the prior art and removal thereof is 
respectfully requested. Similar remarks as discussed above in regard to claim 2 apply to 
claims 20 and 36. 

Regarding claim 5, contrary to the Examiner's assertion, Czerwinski fails to teach 
wherein said indication of the set of desired capabilities comprises an indication of said 
advertisement . Specifically, as noted above, capability credential request messages in 
SDS do not include an indication of desired capabilities. Furthermore, Czerwinski fails 
to disclose that the indication of the set of desired capabilities comprised in a capability 
credential request message comprises an indication of an advertisement for the first 
service. The Examiner's cited passages (Czerwinski, sections 3.1, 3.3, and 34) describe 
SDS servers, certificate authority and capability managers. However, when requesting 
capability credentials, SDS clients do not include any indication of a desired set of 
service capabilities, as noted above. Furthermore, SDS clients do not include an 
indication of an advertisement for a service as part of an indication of a set of desired 
capabilities, when querying an SDS service. Instead, clients include desired capabilities 
in queries to locate service advertisements (e.g. service descriptions) (Czerwinski, section 
3.1, paragraph 5). 

In response to applicants argument above, the Examiner states, "Czerwinski 
discloses the advertisement domain contains the service announcements and contact 
information for the capability manager and certificate authority that are indications] of 
the desired capabilities" without citing any particular portion of Czerwinski. The 
Examiner is presumably referring to Czerwinski's teachings regarding domain 
advertisements, as described in section 3.1, paragraph 1. However, Czerwinski 
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specifically states that each server sends domain advertisements that are authenticated 
messages "containing a list of domains that [the server] is responsible for" (Czerwinski, 
section 3.1, paragraph 1). Plus, contact information for a service is not an indication of 
desired capabilities. Instead, contact information merely provides a means of addressing 
(e.g. sending messages to) an entity in Czerwinski's system. Thus, the domain 
advertisements do not include any indications of desired capabilities. Furthermore, the 
Examiner appears to be arguing that Czerwinski's domain advertisements include 
indications of desired capabilities, which, even if true, which it is not, would be 
completely the opposite of what is recited in Applicants' claim. Claim 5 recites, in part, 
wherein the indication of the set of desired capabilities comprises an indication of the 
advertisement. Thus, the Examiner's contention that a domain advertisement includes 
indications of desired capabilities does not address applicants argument that Czerwinski 
fails to teach that an indication of the set of desired capabilities includes an indication of 
the advertisement. 

Thus, for at least the reasons give above, the rejection of claim 5 is not supported 
by the prior art and removal thereof is respectfully requested. Similar remarks as 
discussed above in regard to claim 2 apply to claims 21 and 37. 

Regarding claim 6, contrary to the Examiner's assertion, Czerwinski fails to teach 
wherein said indication of said advertisement is said advertisement itself . The remarks 
above regarding claim 5 apply to claim 6 as well. Additionally, Czerwinski fails to teach 
including an advertisement for a service in a capability credential request message. The 
Examiner cites passages (Czerwinski, sections 3.1, 3.3, and 3.4) that describe SDS 
servers, capability mangers, and certificate authority. However, nowhere in the 
Examiner's cited passage, nor anywhere else, does Czerwinski describe including an 
advertisement for a service as an indication of the advertisement in a capability credential 
request message. In contrast, Czerwinski teaches that a capability manager receives 
access control lists from services that include lists of principals that are allowed to access 
a service (Czerwinski, section 3.4). A SDS client does not include any indication of an 
advertisement for a service in a capability credential request message and certainly does 
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not include the advertisement itself as the indication of the advertisement in a capability 
credential request message. Instead, a SDS client receives from the capability manager a 
credential that is presented to a SDS server by the client. The SDS server then uses that 
credential to return only services that the client is allowed to access. (See Czerwinski, 
section 3.1, paragraph 5). Thus, Czerwinski clearly fails to teach wherein said indication 
of said advertisement is said advertisement itself. Applicants note that the Examiner 
has failed to provide any rebuttal to Applicants' arguments regarding claim 6. 

Therefore, for at least the reasons given above, the rejection of claim 6 is not 
supported by the prior art and removal thereof is respectfully requested. Similar remarks 
as discussed above in regard to claim 6 apply to claims 22 and 38. 

Regarding claim 7, the Examiner contends that Czerwinski discloses a method 
including wherein said indication of said advertisement is a Uniform Resource Identifier 
(URI) to said advertisement. Applicants respectfully disagree with the Examiner's 
interpretation of Czerwinski. The Examiner cites sections 3.1 and 3.4 of Czerwinski that 
describes the workings of SDS servers and SDS capability managers. Specifically the 
Examiner is relying upon the fact that in SDS "a capability proves the client is on ACL 
[access control list] by embedding the client's principal name and the service name" 
combined with Czerwinski 5 s disclosure regarding the Globe services us globe unique 
object identifier. However, the teachings in Czerwinski that the Examiner is relying upon 
have nothing to do with a capability credential request message. In fact, the cited passage 
of Czerwinski does not mention anything regarding a capability credential request 
message nor does it describe using a URI to an advertisement as an indication of the 
advertisement in a capability credential request message. In contrast, Czerwinski teaches 
that a capability manager receives access control lists from services that include lists of 
principals that are allowed to access a service (Czerwinski, section 3.4). The service 
advertisements in SDS are sent by individual services and are collected by SDS servers to 
compare against client queries (Czerwinski, section 2.3). Nowhere does Czerwinski 
teach that a client includes a URI to an advertisement as an indication of the 
advertisement in a capability credential request message. 
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Furthermore, the Examiner has not established a proper case of anticipation 
because the teachings relied on by the Examiner are from separate works. 

Anticipation requires the presence in a single prior art reference disclosure of each and 
every element of the claimed invention, arranged as in the claim . Lindemann 
Maschinenfabrik GmbH v. American Hoist & Derrick Co., 221 USPQ 481, 485 (Fed. Cir. 
1984). The identical invention must be shown in as complete detail as is contained in the 
claims. Richardson v. Suzuki Motor Co., 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 
Although all the teachings cited by the Examiner are discussed in a single reference, the 
teachings are not part of a single method. For example, the portion of Czerwinski cited 
by the Examiner at section 6.1 pertains to a different service discovery system (DNS) 
than the portion of Czerwinski cited by the Examiner at sections 3.3 and 3.4. To 
anticipate the claimed invention, Czerwinski must teach a single method that is identical 
to Applicants' claimed invention. Otherwise, Czerwinski cannot be said to teach the 
identical invention arranged as in Applicants' claims . Moreover, as discussed above, no 
combination of teachings in Czerwinski teaches Applicants' claimed invention. 

Applicants note that the Examiner has failed to provide any rebuttal to 
Applicants 9 arguments regarding claim 7. 

Thus, the rejection of claim 7 is not supported by the prior art and removal thereof 
is respectfully requested. Similar remarks as discussed above in regard to claim 7 apply 
to claims 23 and 39. 

Section 103(a) Rejections : 

The Office Action rejected claims 8, 24 and 40 under 35 U.S.C. § 103(a) as being 
unpatentable over Czerwinski in view of Vacon et al. U.S. Patent 5,227,778, hereinafter 
"Vacon"). Applicants respectfully traverse this rejection in light of the following 
remarks. 
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Regarding claim 8, contrary to the Examiner's assertion, Czerwinski in view of 
Vacon fails to teach wherein the indication of the advertisement in the capability 
credential request message is a version of the advertisement edited to describe only the 
set of desired capabilities. As described herein above, Czerwinski does not teach the use 
of a capability credential request message that includes an indication of an advertisement. 
The Examiner cites a passage in Vacon that describes how network servers use multi-cast 
request messages to locate services that match a client's request. The Examiner is relying 
upon Vacon' s teaching that a server includes identification, by function, of the requested 
service in the multi-cast request message (Vacon column 2, lines 1-5). However, when a 
server is sending a multi-cast request message including a desired service, it is not 
sending a capability credential request message. Instead, it is a multi-case request 
message to which all services providing the desired service reply (Vacon, column 5, lines 
23-51). 

Further, a server in Vacon' s system does not include a version of an 
advertisement edited to describe only a set of desired capabilities in the multi-cast request 
message. Instead, Vacon clearly teaches that a server saves only the network address of 
the service and discards the remainder of the service advertisement (Vacon, column 2, 
lines 34-46). Thus, under Vacon, the service advertisement is not even saved, much less 
edited to describe only a set of desired capabilities and included in a capability credential 
request message. 

Additionally, the Examiner's proposed combination of Czerwinski in view of 
Vacon would not result in a system that includes wherein the indication of the 
advertisement in the capability credential request message is a version of the 
advertisement edited to describe only the set of desired capabilities. In fact, such a 
combination would result in a system where the SDS servers taught by Czerwinski send 
multi-cast request messages, including an indication of the desired service, to find 
services that match a client's needs. However, since, as noted above, neither Czerwinski 
nor Vacon, discloses a capability credential request message including an indication of 
an advertisement for a service, a combination of Czerwinski and Vacon would also not 
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include a capability credential request message including an indication of an 
advertisement, wherein the indication of the advertisement is a version of the 
advertisement edited to described only the set of desired capabilities. Applicants note 
that the Examiner has failed to provide any rebuttal to Applicants' arguments 
regarding claim 8. 

Thus, the rejection of claim 8 is not supported by the prior art and removal thereof 
is respectfully requested. Similar remarks as discussed above in regard to claim 8 apply 
to claims 24 and 40. 

The Office Action rejected claims 14, 15, 30 and 46 under 35 U.S.C. § 103(a) as 
being unpatentable over Czerwinski in view of Johnson et al. (U.S. Patent 5,560,008) 
(hereinafter "Johnson"). Applicants respectfully traverse the rejection of these claims for 
at least the reasons given above regarding their respective independent claims. 

In regard to the rejections under both sections 102(a) and 103(a), Applicants also 
assert that numerous ones of the dependent claims recite further distinctions over the 
cited art. However, since the rejection has been shown to be unsupported for the 
independent claims, a further discussion in regard to the dependent claims is not 
necessary at this time. 

Information Disclosure Statement : 

Applicants note that an Information Disclosure Statement with accompanying 
Form PTO-1449 was submitted on February 8, 2005. Applicants request the Examiner to 
carefully consider the listed references and return a copy of the signed and initialed Form 
PTO-1449 from this statement. 
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CONCLUSION 



Applicants submit the application is in condition for allowance, and an early 
notice to that effect is requested. 

If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5181- 
70400/RCK. 

Also enclosed herewith are the following items: 
£3 Return Receipt Postcard 
I I Petition for Extension of Time 
I I Notice of Change of Address 
□ Other: 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: April 22. 2005 
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Respectfully submitted, 




Robert C. Kowert ' 
Reg. No. 39,255 

ATTORNEY FOR APPLICANT(S) 



